A first look at the usability of Bitcoin key management Eskandari et al., USEC 2015

This is the third of five papers from the ACM Queue Research for Practice selections on ‘Cryptocurrencies, Blockchains, and Smart Contracts.’ And thankfully it’s much easier to read and understand than yesterdays! The authors point out that a cryptocurrency intended for use by the general public also needs a means by which the general public can come to understand and manage collections of public and private keys. To date, this has proved elusive. As the authors of “Why Johnny Can’t Encrypt” point out, “Security mechanisms are effective only when used correctly.” One of the interesting takeaways for me is that the familiar metaphors of ‘coin’ and ‘password’ can harm as much as they help.

In all of the excitement surrounding Bitcoin, it is easy to forget that the decentralized currency assumes a solution to the longstanding problem of usable public key cryptography for user authentication.

If you lose a Bitcoin private key, you lose the monetary value of the coins it protects. Moreover, Bitcoin users typically have no legal protection against loss or theft. So can we find a safe, usable key management approach for novice users? The findings from previous studies on the usability of public key cryptography include:

1. The metaphor and terminology behind public and private keys is confusing
2. It is difficult to correctly obtain other user’s public keys
3. Key migration between devices is difficult

Many of the confusions seem to stem from the fact that users are used to passwords for protecting information, and public/private key pairs don’t fit neatly into that mental model.

The main bulk of the paper compares and contrasts six different approaches to Bitcoin key management, followed by a more detailed usability study of six actual Bitcoin clients, one from each category.

Six approaches to Bitcoin key management

Here are six different approaches that you might use for managing private keys:

1. Keep them on device local storage. Bitcoin Core uses this approach. It’s easy, but vulnerable to malware since the file storing private keys can be read by any process with applications to the user’s folder. Private-key stealing malware has been known since at least 2011. Users need to be very careful not to inadvertently share this folder outside of their computer, but at the same time they need to periodically create new backups of the key storage file to ensure that new keypool keys are stored.
2. Use a password-protected encrypted wallet. MultiBit uses this approach. These solutions encrypt the key storage file that is held on device local storage. The user is therefore protected against theft of the file (to the degree the password cannot be cracked), but malware on the machine will still be able to use e.g. a keystroke logger to capture the password. “Password-protected wallets may mislead the user to believe that the password itself provides access to their funds regardless of the location of the device storing the wallet.
3. Offline storage of keys (e.g., Bitaddress) To protect against malware-based threats, wallets can be stored offline on portable media (e.g., a USB drive). Of course, this makes the wallet unavailable for immediate use, and the wallet is still exposed and potentially vulnerable to malware when mounted on a computational device. An interesting example here is paper wallets (e.g. https://bitcoinpaperwallet.com), though users still need to to be trained not to allow the private key QR code to be observed.
4. Air-gapped key storage (Armory supports this approach). Here wallets are stored on a secondary device that is never connected to a network. This device is used to generate, sign, and export transactions. Care must be taken not to infect the air-gapped device with malware when e.g., inserting portable media to export the signed transactions. Hardware security modules (HSMs) emulate the properties of an air gap. Trezor for example build a Bitcoin-specific HSM based device.
5. Password-derived keys (e.g., Brainwallet), in which cryptographic keys are derived from a user-chosen password – although this requires one password per key pair in the basic scheme. A Hierarchical Deterministic wallet derives a whole set of keys from a randomly chosen passphrase serving as the master secret. It’s only as good as the chosen password though.
6. Hosted wallets (e.g. Blockchain.info). These are services which host a wallet for you, and provide access through standard web authentication mechanisms. “It is natural to expect hosted wallet services will become primary targets of attack since these services typically hold large amounts of Bitcoin.”

The following table compares these six approaches using 10 different criteria. Note also the comparisons to cash and traditional online banking in the bottom two rows.

(Click on image for larger view).

Based on our analysis, users can be given the concrete advice of treating digital currency much like they would treat fiat currency: keeping small amounts in ready-to-spend form (e.g., local storage or online hosted walled) mimicking cash, and keeping larger sums in more difficult to access but more secure storage (e.g., air-gapped or offline storage) mimicking a savings account or trust fund.

I’ve not done any detailed research on it, but I have to say I was impressed with the Trezor offering as a practical ‘HSM-gapped’ solution.

Evaluating real-world clients

Bitcoin Core, Multibit, Bitaddress, Armory, Brainwallet, and Blockchain.info are evaluated across four tasks:

• T1: configuring a new Bitcoin address and obtaining its balance
• T2: sending some amount of Bitcoin to an arbitrary (but valid) Bitcoin address
• T3: spending Bitcoin as in T2 above, but this time from a secondary device
• T4: recovering from the loss of the main credential

Since the focus of our walkthrough was on configuration and learnability, we used a set of heuristics first developed for a usability evaluation of Tor:

• G1 Users should be aware of the steps they have to perform to complete a core task.
• G2 Users should be able to determine how to perform
  these steps.
• G3 Users should know when they have successfully completed a core task.
• G4 Users should be able to recognize, diagnose, and
  recover from non-critical errors.
• G5 Users should not make dangerous errors from which
  they cannot recover.

• G6 Users should be comfortable with the terminology
  used in any interface dialogues or documentation.

• G7 Users should be sufficiently comfortable with the
  interface to continue using it.
• G8 Users should be aware of the application’s status at
  all times.

Here’s a summary of the goals on which the various clients failed (taken across all four tasks). See section VI in the full paper for details.

Conclusions

Bitcoin’s usability limitations, particularly those related to key management, pose challenges to its rising popularity. In our evaluation, we found that developers in the Bitcoin ecosystem are making innovative attempts at solving the decades-old problem of usable key management. While some of these techniques seem promising, we find that tasks involving key management can be mired in complex metaphors and confusing abstractions.